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1 

Parallel Text Execution on Low-End Emulators and 

Devices 

CROSS-REFERENCE TO RELATED APPLICATIONS 

[0001] This application claims the benefit of Provi- 

5 sional Application No. 60/443,795. This application is related 
to Application No. (STC File No. 47900), entitled, Automated 
Test Execution Framework with Central Management . 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention . 

•10 [0002] The present invention relates generally to hard- 

ware and software testing and verification, and specifically to 
testing software on low-end emulators and computing devices. 

2. Description of the Related Art. 

[0003] The meanings of acronyms and certain terminology 

15 used herein are given in Table 1: 



Table 1 



API 


Application programming interface 


CLDC 


Connected, limited device configuration. CLDC 
is suitable for devices with 16/32-bit 
RISC /CISC microprocessors /controllers , having 
as little as 160 KB of total memory available. 


HTTP 


HyperText Transfer Protocol 


ID 


Identifier 


IP 


Internet Protocol 


J2EE 


Java 2 Enterprise Edition 


J2ME 


Java 2 Micro Edition 


J2SE 


Java 2 Standard Edition 


JAD 


Java application descriptor 


JAM tags 


Mandatory fields in a JAD file 


JAR 


Java archive 


MIDlet 


A MIDP application 


MIDP 


Mobile information device profile. A set of 
Java APIs, which, together with the CLDC, 
provides a complete J2ME application runtime 
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environment targeted at mobile information 
devices . 

[0004] MIDP is defined in Mobile Information Device 

Profile (JSR-37), JCP Specification, Java 2 Platform, Micro 
Edition, 1.0a (Sun Microsystems Inc., Palo Alto, California, 
5 December 2000) . MIDP builds on the Connected Limited Device 
Configuration (CLDC) of the Java 2 Platform, Micro Edition 
(J2ME) (available from Sun Microsystems Inc., Palo Alto, Cali- 
fornia) . The terms Sun, Sun Microsystems, Java, J2EE, J2ME, 
J2SE, and the Sun logo are trademarks or registered trademarks 

10 of Sun Microsystems, Inc., in the United States of America and 
other countries. All other company and product names may be 
trademarks of their respective companies. A portion of the dis- 
closure of this patent document contains material that is sub- 
ject to copyright protection. The copyright owner- has no objec- 

15 tion to the facsimile reproduction by any one of the patent 
document or the patent disclosure, as it appears in the Patent 
and Trademark Office patent file or records, but otherwise re- 
serves all copyright rights whatsoever. 

[0005] Tools have been developed in recent years to aid 

20 in the design verification of hardware and software systems, 
for example software suites, hardware circuitry, and programma- 
ble logic designs. In order to assure that the design complies 
with its specifications, it is common to generate a large num- 
ber of input or instruction sequences to assure that the design 

25 operates as intended under a wide variety of circumstances. In 
general, test systems produce a report indicating whether tests 
have been passed or failed, and, in some cases may even indi- 
cate a module that is estimated to be faulty. 

[0006] Conventionally, to test a device under develop- 

30 ment (such as a mobile information device) , or to test software 
designed to run on such a device, a developer connects the de- 
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vice to an appropriate test system. The target device under 
test may be connected to the test system either directly or via 
a communication emulator. The developer selects a battery of 
test programs to run on the target device while monitoring its 
5 behavior. Running the complete battery of tests can commonly 
take many hours or even days. This problem is particularly 
acute in testing low-end computing devices, such as cellular 
telephones and other mobile information devices, which have 
limited computing power and memory resources. Thus, testing on 
10 the target device can become a serious bottleneck in the devel- 
opment cycle. 

SUMMARY OF THE INVENTION 

[0007] Embodiments of the present invention provide 

methods and systems for parallel testing of multiple low-end 

15 computing devices, such as mobile information devices. Multiple 
computing devices are connected to a test server, either di- 
rectly or via an emulator. Each of the devices is assigned a 
unique identifier (ID) , which allows the server to keep track 
of which tests have been assigned to and carried out by each 

20 device. Whenever a device completes a test (or a bundle of 
tests), it reports the results to the server and requests the 
next text to execute, using its unique identifier in the mes- 
sages that it sends to the server. Based on the unique identi- 
fier and the report, the server selects the next test or test 

25 bundle to assign to this device. This mechanism enables the 
server to balance and track the load of testing among an arbi- 
trarily large number of client devices, and thus to complete 
the test suite in far less time than is required by test sys- 
tems known in the art. 

30 [0008] The invention provides a method for testing com- 

puting devices, which is carried out by providing a suite of 
test programs on a server for execution by a plurality of the 
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computing devices that are coupled to the server, assigning a 
respective unique identifier to each of the plurality of the 
computing devices for use in communicating with the server, 
downloading the test programs from the server "for execution by 
5 the computing devices coupled thereto, so that at least first 
and second computing devices among the plurality execute dif- 
ferent first and second test programs from the suite substan- 
tially simultaneously. The method "further includes receiving 
messages at the server from the computing devices with respect 

10 to the execution of the test programs, each of the messages 
containing the respective unique identifier, and controlling 
the execution of the first and second test programs in the 
suite based on the messages. 

[0009] According to one aspect of the method, the com- 

15 puting devices are MIDP-compliant devices, and the test pro- 
grams are MIDlets, which are packaged in respective JAD files 
and JAR files, and the method includes downloading the JAD 
files and the JAR files to the MIDP-compliant devices. 

[0010] Yet another aspect of the method includes evalu- 

20 ating the JAD files, wherein the JAR files are downloaded re- 
sponsively to the evaluation of the JAD files. 

[0011] According to another aspect of the method, at 

the test program comprises a bundle of tests, and requests are 
received from the computing devices to determine a next test to 

25 execute in the bundle. Responsively to a selection at the 
server, based on the respective unique identifier contained in 
the requests, a determination is made of the next test to exe- 
cute on each of the computing devices, and messages are sent 
from the server to the computing devices indicating the selec- 

30 tion. 

[0012] According to a further aspect of the method, the 

respective unique identifier of each of the computing devices 
includes an IP address. 
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[0013] According to yet another aspect of the method, 

assigning the respective unique identifier includes receiving 
an initial request from each of the computing devices to down- 
load one of the test programs, and assigning the respective 
5 unique identifier in response to the initial request. 

[0014] According to still another aspect of the method, 

the computing devices are coupled to the server via a common 
test host, wherein an identifier of the common test host is 
shared by each of the computing devices in the respective 
10 unique identifier thereof. 

[0015] The invention provides a computer software prod- 

uct, including a computer-readable medium in which computer 
program instructions are stored, which instructions, when read 
by a computer, cause the computer to perform a method for test- 
is ing computing devices, which is carried out by providing a 
suite of test programs on a server for execution by a plurality 
of the computing devices that are coupled to the server, as- 
signing a respective unique identifier to each of the plurality 
of the computing devices for use in communicating with the 
20 server, downloading the test programs from the server for exe- 
cution by the computing devices coupled thereto, so that at 
least first and second computing devices among the plurality 
execute different first and second test programs from the suite 
substantially simultaneously. The method further includes re- 
25 ceiving messages at the server from the computing devices with 
respect to the execution of the test programs, each of the mes- 
sages containing the respective unique identifier, and control- 
ling the execution of the. first and second test programs in the 
suite based on the messages. 
30 [0016] The invention provides a server for testing com- 

puting devices, including a communication interface for cou- 
pling a plurality of the computing devices thereto, such that a 
respective unique identifier is assigned to each of the plural- 
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ity of the computing devices for use in communicating with the 
server, via the communication interface. The server is adapted 
to provide a suite of test programs for execution by the com- 
puting devices that are coupled to the server, and to download 
5 the test programs via the communication interface for execution 
by the computing devices coupled thereto, so that at least 
first and second computing devices among the plurality execute 
different first and second test programs from the suite sub- 
stantially simultaneously. The server is further adapted to re- 

10 ceive messages via the communication interface from the comput- 
ing devices with respect to execution of the test programs, the 
messages containing the respective unique identifier, and to 
control the execution of the test programs in the suite based 
on the messages and the respective unique identifier therein by 

15 communicating responses to the messages via the communication 
interface, wherein each of the responses is addressed to a re- 
spective one of the computing devices that is associated with 
the respective unique identifier. 

[0017] According to an aspect of the server, the corti- 

20 puting devices are coupled to the communication interface via a 
common test host, wherein an identifier of the common test host 
is shared by each of the computing devices, and the identifier 
of the common test host is included in the respective unique 
identifier thereof . 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

[0018] For a better understanding of the present inven- 

tion, reference is made to the detailed description of the in- 
vention, by way of example, which is to be read in conjunction 
with the following drawings, wherein like elements are given 
30 like reference numerals, and wherein: 

[0019] Fig. 1 is a block diagram that schematically il- 

lustrate systems for parallel testing of low-end computing de- 



P9339 



47979 



Ver. 47979S4.doc 



vices, in accordance with an embodiment of the present inven- 
tion; 

[0020] Fig. 2 is a block diagram that schematically il- 

lustrate systems for parallel testing of low-end computing de- 
5 vices, in accordance with an alternate embodiment of the pre- 
sent invention; 

[0021] Fig. 3 is a block diagram that schematically il- 

lustrates program components used in a test system, in accor- 
dance with an embodiment of the present invention; 
10 [0022] Fig. 4 is a detailed flow chart that schemati- 

cally illustrates a method for parallel testing of low-end com- 
puting devices, in accordance with an embodiment of the present 
invention; and 

[0023] Fig. 5 is a flow chart that schematically illus- 

15 trates a method for parallel testing of low-end computing de- 
vices, in accordance with an embodiment of the present inven- 
tion . 

DETAILED DESCRIPTION OF THE INVENTION 

[0024] In the following description, numerous specific 

20 details are set forth in order to provide a thorough under- 
standing of the present invention. It will be apparent to one 
skilled in the art, however, that the present invention may be 
practiced without these specific details. In other instances 
well-known circuits, control logic, and the details of computer 
25 program instructions for conventional algorithms and processes 
have not been shown in detail in order not to unnecessarily ob- 
scure the present invention. 

[0025] Software programming code, which embodies as- 

pects of the present invention, is typically maintained in per- 
30 manent storage, such as a computer readable medium. In a cli- 
ent/server environment, such software programming code may be 
stored on a client or a server. The software programming code 
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may be embodied on any of a variety of known media for use with 
a data processing system, This includes, but is not limited to, 
magnetic and optical storage devices such as disk drives, mag- 
netic tape, compact discs (CD's), digital video discs (DVD's), 
5 and computer instruction signals embodied in a transmission me- 
dium with or without a carrier wave upon which the signals are 
modulated. For example, the transmission medium may include a 
communications network, such as the Internet. 

[0026] Reference is now made to Fig. 1, which is a 

10 block diagram that schematically illustrates a system 20 for 
parallel testing of multiple mobile information devices 24, in 
accordance with an embodiment of the present invention. The 
system 20 is built around a test server 22, which is described 
in greater detail hereinbelow. The devices 24 are client de- 

15 vices, and are typically low-end devices, with limited comput- 
ing power and memory, for example, cellular telephones or per- 
sonal digital assistants (PDA's). In the description that fol- 
lows, the devices 24 are assumed to comply with MIDP, but the 
principles of the present invention are equally applicable to 

20 other types of low-end computing devices, operating in accor- 
dance with other standards and specifications. The server 22 
typically comprises a programmable processor, and has suitable 
communication interfaces, such as wireless or wired interfaces, 
for communicating with multiple devices 24 simultaneously. 

25 [0027] Each of the devices 24 receives a unique identi- 

fier for communicating with the server 22. Typically, the 
unique identifier may comprise a unique Internet Protocol (IP) 
address that is assigned to each of the devices 24 for communi- 
cating with the server 22. Alternatively, the server may assign 

30 IDs of other types, or the ID' s. may be assigned by a user upon 
initiating communication between one or more of the devices 24 
and the server 22. Methods for assigning and using these IDs 
are described in detail 'hereinbelow. 
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[0028] Reference is now made to Fig. 2, which is a 

block diagram that schematically illustrates a system 30 for 
parallel testing of multiple devices 24, in accordance with an- 
other embodiment of the present invention. In this embodiment, 
5 the server 22 communicates with the devices 24 through a test 
host 32, such as a personal computer or workstation. Multiple 
test hosts of this sort may be connected to the server 22 in 
parallel, but only a single host is shown in Fig. 2 for the 
sake of simplicity. The host 32 can simultaneously accommodate 

10 multiple devices 24, but the host 32 typically has only a sin- 
gle IP address. Therefore, in this embodiment, the IP address 
cannot be used conveniently to identify the individual de- 
vices 24, and an alternative unique identifier is typically 
used, as described below. 

15 [0029] Reference is now made to Fig. 3, which is a 

block diagram that schematically illustrates software program 
components running on the server 22 and the devices 24, in ac- 
cordance with an embodiment of the present invention. Elements 
of this software may be provided to the server 22 and to the 

20 devices 24 on tangible media, such as optical or magnetic stor- 
age media or semiconductor memory chips. The software may be 
downloaded to the server 22, and alternatively or additionally, 
to the devices 24 in electronic form, for example, over a net- 
work or over the air. 

25 [0030] The server 22 comprises a test framework 40, 

which generates and deploys the tests to be carried out by the 
devices 24. The test framework 40 may be implemented as the 
"Java Device Test Suite" execution framework (JDTS) (ver- 
sion 1.0 or higher), available from Sun Microsystems, Inc., 

30 which employs MIDP. A suitable version of the test framework 40 
is described, for example, in the above-mentioned Application 
No. (STC File No. 47900), which is commonly assigned herewith, 
and is herein incorporated by reference. 
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[0031] The tests typically are packaged in the form of 

Java applications contained in a set of JAD and JAR files. Each 
JAR file of this sort, together with its accompanying JAD file, 
is referred to hereinbelow as a test bundle 52. Users of the 
5 system 20 (Fig. 1) or the system 30 (Fig. 2) interact with the 
test framework 40 in order to select the tests to be executed 
by the system. Alternatively, other test frameworks may be used 
for generating the required test files, as will be apparent to 
those skilled in the art. 

10 [0032] A test manager 42 in the server 22 is responsi- 

ble for serving requests from the devices 24, based on the 
unique client identifiers mentioned above. Typically, whenever 
one of the devices 24 makes a request, the test manager 42, 
typically operating as a main thread, reads the request and as- 

15 signs a new thread 44 to handle it. This thread 44 retrieves 
the client unique identifier from the request, calls the compo- 
nents of the test framework 40 that are needed to process the 
request, and then returns the appropriate response to the cli- 
ent device, as described hereinbelow. After assigning the 

20 thread 44 to handle the client, the main thread of the test 
manager 42 waits for the next client request. Each client re- 
quest is handled by a separate thread 44, which terminates upon 
completion of processing. This ■ arrangement , together with the 
unique identifier mechanism, ensures that the server 22 will be 

25 able to handle multiple devices 24 simultaneously without con- 
fusion. 

[0033] In order to run Java applications, the de- 

vices 24 contain an implementation of the Connected Limited De- 
vice Configuration specification, CLDC 46, with an implementa- 
30 tion of the Mobile Information Device Profile specification, 
MIDP 48, running over the CLDC 46. The applications that run on 
this technology, such as the tests supplied by framework 40, 
are known as MIDlets. These applications are created by extend- 
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ing an API MIDlet class of the MIDP 48. Thus, each test bun- 
dle 52 is actually a MIDlet, packaged in the form of a JAD/JAR 
file pair. 

[0034] The test bundle 52 is typically downloaded to 

5 the devices 24 in a two-step process: 

[0035] 1. The server 22 downloads the JAD 

file, which contains environment settings and some 
environment demands. Application Manager Software, 
AMS 50, which is typically a part of a browser built 

10 into the devices 24, evaluates the JAD file to ensure 

that the device is able to accept the MIDlet. For ex- 
ample, the JAD file for a given MIDlet may specify 
that the device must support MIDP version 2.0. If the 
device does not support this version, the AMS 50 re- 

15 jects the application download, and saves the time 

that would otherwise be consumed by downloading the 
much larger JAR file. 

[0036] 2. After completing all the relevant 

checks, the AMS 50 reads from the JAD file the loca- 

20 tion of the corresponding JAR file on the server 22 

and asks to download the JAR file to one or more of 
the devices 24. The JAR file contains all the rele- 
vant classes of the test bundle 52. 

[0037] Once the JAR file for the test bundle 52 is 

25 downloaded to one of the devices 24 and stored in the local de- 
vice memory, the device is ready to run the tests of the test 
bundle 52. Every JAR file that the AMS 50 downloads to the de- 
vices 24 typically contains an agent 54, which is used to run 
the tests, in addition to classes corresponding to the tests 
30 themselves. To start test execution the AMS 50 runs the agent 
class. The agent 54 then addresses the server 22 in order to 
receive instructions regarding the next test to run 
(getNextTest ) and to report test results (sendTestResult ) , 
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typically using a protocol based on HTTP. Each test in the test 
bundle 52 corresponds to a respective class in the JAR file. 
Each client request that is addressed by the agent 54 to the 
server 22 includes the unique identifier that has been assigned 
5 to the particular one of the devices 24, so that the server 22 
is able to recognize the client and serve it in the correct 
manner . 

Implementation Details . 

[0038] Further details of the implementation of the 

10 server 22 are given in Listing 1 (class BaseHttpServer ) . An im- 
plementation of the communications interface through which re- 
quests and messages are transmitted between the server 22 and 
the devices 24 is detailed in Listing 2 (class Communicator) . 
Runtime generation of JAD files by the server 22 is accom- 

15 plished using Listing 3 (class HttpServer) . Launching of the 
agent 54 is detailed in Listing 4 (class MIDPRunner) . Implemen- 
tation of the thread 44 is detailed in Listing 5 (class Server- 
TaskThread) . 

[0039] Listing 6 shows a class (class Extender) that is 

20 needed by the classes shown in Listings 1 - 5. A brief descrip- 
tion of Listing 6 follows. 

[0040] A public interface Extender provides access to a 

class Extender. The class Extender enables an agent link with 
platforms that require extensions of their main application 
25 class, for example to properly employ a system class, such as 
class Applet or class MIDlet. The class Extender accepts dele- 
gation of platform specific commands from an agent. 

[0041] The interface Extender includes the following 

methods. A method getRunnerExtender retrieves a reference to a 
30 platform class, which the main application class extends. Using 
this method, an agent provides access to the test program by 
the main application class in the context in which it is cur- 
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rently executing. An object is returned, which can be cast to 
the system class that the extender class extends. A method ter- 
minateAgent provides a platform-specific way of application 
termination . 

5 [0042] It will be understood that Listings 1-6 are 

exemplary, and the functions and operations shown therein can 
be accomplished using other techniques known to the art. 

[0043] Reference is now made to Fig. 5, which is a high 

level flow chart that schematically illustrates a method for 

10 running test suites on multiple client devices 24 in the sys- 
tem 20 (Fig. 1) or the system 30 (Fig. 2), in accordance with 
an embodiment of the present invention. The flow chart in 
Fig. 5 presents an interaction involving only a single client 
request for clarity. However, the method can be performed si- 

15 multaneously, with many clients. Indeed, different devices may 
be executing different tests, or even different test suites or 
test bundles at any given time. This method is explained with 
reference to the software structures shown in Fig. 3, although 
other implementations are also possible, as will be apparent to 

20 those skilled in the art. The method begins at initial 
step 100, which is a configuration step. A server is attached 
to a plurality of client devices to be tested using suitable 
communications links . 

[0044] Next, at delay step 102 the server awaits a re- 

25 quest from a client. As will be apparent from the discussion 
below, the request could be for a new test bundle, or for the 
next test in a test bundle that is currently executing. 

[0045] Upon receipt of a client request, control pro- 

ceeds to decision step 104. Here it is determined whether the 

30 client request received at delay step 102 is a request for a 
new test bundle. This is normally the case when the client is 
first recognized by the server. Otherwise, such a request can 
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occur if a previous test bundle has been completed by a client 
already known to the server according to its unique identifier. 

[0046] If the determination at decision step 104 is 

negative, then generally, the server is already aware of the 
5 requesting client. Control proceeds to decision step 106, which 
is disclosed below. 

[0047] If the determination at decision step 104 is af- 

firmative, it is concluded that the server has not previously 
interacted with the requesting client. Control proceeds to 

10 step 108. Here a unique identifier is assigned to the request- 
ing client. Whichever of the alternate methods disclosed herein 
for making the assignment is employed, the client is uniquely 
identified at step 108, and its subsequent requests and results 
will be handled without possibility of confusion with other 

15 currently attached clients. As noted above different clients 
may be identically configured, and may even be concurrently 
executing the same test bundle. Furthermore, any test results 
reported by the now uniquely identified client are accurately 
associated with that particular client so as to guarantee the 

20 integrity of test reports that may be eventually generated by 
the server. Control now proceeds to step 110. 

[0048] At step 110 a JAD file corresponding to the cli- 

ent request is generated or selected by the server for trans- 
mission to the client. Control then proceeds to step 112, which 

25 is disclosed below. 

[0049] Decision step 106 is performed when the determi- 

nation at decision step 104 is negative. Here it is determined 
if the client request received at delay step 102 is a request 
for the next test to be executed in a current test bundle. Such 

30 requests may be generated at the client responsively to evalua- 
tion at the client of a previously downloaded JAD file, based 
on suitability of the tests for the particular client. 
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[0050] If the determination at decision step 106 is af- 

firmative, then control proceeds to step 114. The server re- 
trieves the test record that corresponds to the next test to be 
executed by the client. It will be apparent that this mechanism 
5 provides a high degree of central control by the server, so as 
to optimize the order of test execution by different clients. 
For example, if the server has received borderline test results 
from the client, it could elect to repeat a particular test, or 
to perform supplemental tests that would otherwise be skipped. 

10 [0051] If the determination at decision step 106 is 

negative, then it is concluded that an unrelated client request 
has been made. For example, the client may have requested 
transmission of test results, or a display illustrating the 
profile of a test. Control proceeds to step 116, where this re- 

15 quest is processed. 

[0052] Next, at step 112 a response to the client re- 

quest is assembled. Test information obtained in step 114, a 
JAD file obtained in step 110, or information relating to the 
request processed in step 116, whichever is applicable, is now 

20 concatenated with the client's unique identifier. 

[0053] Next, at step 118, the response assembled at 

step 112 is downloaded to the requesting client. Control then 
returns to delay step 102, where the next client request is 
awaited. 

25 [0054] Reference is now made to Fig. 4, which is a de- 

tailed flow chart that schematically illustrates the method 
shown in Fig. 5 in further detail, in accordance with an em- 
bodiment of the present invention. The method begins with se- 
lection of the tests to be run, at a test selection step 60. 

30 This step is generally performed by a user, such as a develop- 
ment engineer, through interaction with the framework 40. Based 
on the user selections, the framework 40 deploys the selected 
tests, at a deployment step 62. At this step, the test frame- 
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work creates a list of test bundles 52 (JAD/JAR file, pairs), 
which also include the agent 54, as described above. When the 
deployment phase is completed, bundles 52 are ready to be 
downloaded to the devices 24, and the server 22 waits for the 
5 devices 24 to connect at a server waiting step 64. 

[0055] Each of the devices 24 that is linked to the 

server 22 makes an initial connection with the server 22 and 
requests a test bundle 52, at a bundle request step 66. The 
syntax for this initial request is typically: 

10 http : //<server_name> : <server_j?ort>/getNextApp . j ad. 

[0056] Every time one of the devices 24 addresses the 

server 22 at step 66, the server assigns the device a unique 
identifier. The server 22 then sends a JAD file to the client 
device containing the unique identifier, along with other in- 

15 formation regarding the test bundle 52, at a JAD download 
step 68. Typically, the server 22 marks the associated JAR file 
as "in use, " to ensure that the same test bundle is not inad- 
vertently assigned to two devices 24. The AMS 50 stores the 
unique identifier in the local memory of the appropriate one of 

20 the devices 24. Thereafter, each time this device addresses the 
server, it retrieves the unique identifier from its memory and 
concatenates the unique identifier to the request in order to 
request the next test to perform, for example as follows: 
http : //<server_name> :.<server_port>/getNextTest /<ID> . 

25 [0057] If each of the devices 24 that is linked to the 

server 22 has a unique IP address, this IP address may be used 
by the server 22 as the unique identifier for the respective 
device. When the devices 24 communicate with the server 22 us- 
ing HTTP, one of the client request parameters is simply the IP 

30 source address, so that the unique identifier is naturally con- 
tained in every request. 

[0058] Alternatively, in some cases, such as the sys- 

tem 30 (Fig. 2), multiple devices 24 may use the same IP ad- 
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dress in communicating with the server 22. Thus, upon receiving 
the initial client request at step 66, the server 22 may recog- 
nize that the IP source address is already in use as a unique 
identifier by another one of the devices 24. In this case, the 
5 test manager 42 creates a new unique identifier for the current 
client device, typically by concatenating the client's IP ad- 
dress with a sequential number, to which the server 22 has ac- 
cess, and which is inaccessible to network elements other than 
the server 22 and the devices 24. 

10 [0059] Further alternatively, an outside ID manager 

(not shown) may be used to assign client unique identifiers, 
either automatically or under control of the user. Thus, for 
example, if the initial connection request issued by one of the 
devices 24 has the form: 

15 http : //< serve r_name> : <server_port>/getNextApp, 

the request is extended by the ID manager to be 
http : //<server_name> : <server_port>/getNextApp/l . The next con- 
nection request, by another client device, is extended to be 
http : //<server_name> : <server_port>/getNextApp/2 ; and so on. The 

20 server 22 assumes that the outside ID manager is reliable, and 
assigns to each of the devices 24 a respective unique identi- 
fier that is appended to the first request from the device. 

[0060] In deciding which JAD file to send at step 68, 

the server 22 consults a list of test bundles created at 

25 step 62 to determine which test bundles have not yet been as- 
signed. It may parcel out the different test bundles among dif- 
ferent devices 24 in such a way that the testing load is bal- 
anced among the devices, and all the devices 24 therefore com- 
plete their respective shares of the test suite at approxi- 

30 mately the same time. The load balancing is done according to a 
controlling policy, which is not necessarily according to exe- 
cution time of the different test bundles or components of the 
test bundles. The test manager 42 may also take into account 
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sequential testing relationships among the test bundles, for 
example, that a test bundle B should be carried out only by a 
client device that has successfully passed the tests in a test 
bundle A. On the other hand, the server 22 may decide at 
5 step 68 not to send any test bundle to the client device in 
question, for example because there are no more test bundles to 
execute. If a client device does not receive a JAD file after 
submitting its request at step 66, the device exits from the 
test program, at a client termination step 70. 

10 [0061] Assuming one of the devices 24 receives a JAD 

file, however, the AMS 50 checks the environment settings in 
the JAD file, at an environment checking step 72. The AMS may 
determine that the MIDP 48 or the CLDC 46 or other resources of 
the device, such as memory or display capacity, are incompati- 

15 ble with the environment settings required for the test bun- 
dle 52, at an environment rejection step 74. In this case, as 
well, the client device exits, after notifying the user of sys- 
tem 20 that the settings are incorrect, and test execution 
stops . 

20 [0062] Once the AMS 50 has determined that one of the 

devices 24 is able to carry out the test bundle indicated by 
the JAD file, it asks the test manager 42 to download the cor- 
responding JAR file, at a JAR request step 76. The location of 
the JAR file on the server 22 is provided by the JAD file, and 

25 this location is invoked by the AMS 50 in requesting the JAR 
file. The test manager 42 reads the JAR file from the test 
framework 40 and downloads it to the device at a JAR download 
step 78. The AMS 50 stores the JAR file in the local memory of 
device and runs the class of the agent 54 to begin the tests in 

30 the test bundle 52. 

[0063] When the agent 54 is invoked in this manner, it 

retrieves the unique identifier of one of the devices 24 from 
the local memory of the device, at a first unique identifier 
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retrieval step 80. It will be recalled that the unique identi- 
fier was passed from the server 22 to the device in the JAD 
file downloaded at step 68 . ' The agent 54 uses this unique iden- 
tifier in asking the server 22 for the name of the next test to 
5 be run, at a next test request step 82. This request has the 
general form: 

http : / / < s e r ve r __n ame > : <server_port>/getNextTest /<ID> . 
The server 22 uses the unique identifier to determine the next 
test to be run in the bundle currently assigned to this client 
10 device. The server 22 returns the name of the next test - actu- 
ally the class name of the desired test in the current test 
bundle 52 - to the client device, at a next test determination 
step 84. 



15 agent 54 ascertains that the reply has named one of the classes 
in the present test bundle, at a next test checking step 86. If 
so, the agent runs the class named by the server 22 at a test 
execution step 88. Upon completing the test corresponding to 
the named class, the agent 54 prepares to report the test re- 

20 suits to the server 22. For this purpose, the agent 54 again 
reads the unique identifier of the device, at a second unique 
identifier retrieval step 90. It uses this unique identifier in 
reporting the test results to the server 22, at a result re- 
porting step 92, in the general form: 

25 http : // <server_name> : <server_port>/sendTestResults/<ID> . 

The server 22 receives the test record from the device, and 
adds the record to a test report, at a test recording step 94. 
This report is later submitted to the user of the test system 
upon completion of the test suite, or upon demand by the user. 

30 The agent 54 then returns to step 82 to request the next test 
to run. 



at step 84 that there are no more tests to run in the current 



[0064] 



Upon receiving the reply from the server 22, the 



[0065] 



On the other hand, the server 22 may determine 
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test bundle. In this case, at step 86, the agent 54 is informed 
that the test bundle has been completed. The agent 54 returns 
control to the AMS 50, which then asks the server 22 for the 
next bundle of tests to be executed, at step 66. This process 
5 continues until the entire test suite specified at step 60 is 
completed, unless the server 22 exits earlier due to a system 
error . 

[0066] Although the embodiments described hereinabove 

are based on the Java programming language and Java-related 

10 conventions, as well as on certain specific protocols and de- 
vice specifications, such as CLDC and MIDP, the principles of 
the present invention may similarly be applied to low-end com- 
puting devices using other languages, conventions, protocols 
and specifications. It will thus be appreciated that the em- 

15 bodiments described above are cited by way of example, and that 
the present invention is not limited to what has been particu- 
larly shown and described hereinabove. Rather, the scope of the 
present invention includes both combinations and subcombina- 
tions of the various features described hereinabove, as well as 

20 variations and modifications thereof, which' would occur to per- 
sons skilled in the art upon reading the foregoing description 
and which are not disclosed in the prior art. 



COMPUTER PROGRAM LISTINGS 



25 Listing 1 

public abstract class BaseHttpServer implements Runnable { 
/** 

* "Runnable" is a standard Java class. 
30 * 

* Current tests is a hash table, which hold current tests 

* for each midp client 

* according to its signature. 
*/ 
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private Hashtable currentTests = new Hashtable ( ) ; 



5 *The class that manage the distribution of the 

* bundles to the clients, 

* and dealing with requests that related to the 

* bundles such as get next test. 
*/ 

10 public TestProvider getTes tProvider ( ) { 

return testProvider ; 

} 

/** 

15 *Set the current test of a specific client. 

*/ 

public void setCurrentTes t 

(String signature, byte[] args ) 

{ 

20 currentTests . put (signature, args); 

} 

/** 

*Get the current test of a specific client. 
25 */ 

public byte[] getCurrentTest ( String signature) 

* { 

byte[] currentTest = 

* (byte[]) currentTests . get (signature); 
30 return currentTest; 

} 

*Remove the current test of a specific client. 
35 */ 

public void removeCurrentTest ( String signature)! 
currentTests . remove ( signature ) ; 

} 



40 



45 



public void setTestProvider ( TestProvider tp) { 
testProvider = tp; 

mainClass = tp . getAppMainClass ( ) ; 
// The MIDlet name 

if (mainClass == null) { 

throw new NullPointerException 
("Provider main class not defined"); 

} 
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jarSourceDir = tp . get JarSourceDirectory ( ) ; 

//the directory of the JAR files, 
if (mainClass == null) { 

throw new NullPointerExcept ion 
("Provider jar source directory not defined"); 



10 ' 

public void run() { 
Socket conn = null; 
aborted = false; 
started = true; 
15 synchronized! this ) { 

notif y ( ) ; 

} 

while ( ! done ) { 
20 try { 

try { 

conn = socket . accept () ; 

//retrieve the IP from the connection 
String ipAddress = 
25 conn . get InetAddress ( ) . getHos tAddress ( ) ; 

//assign new thread to process 
// the client request. 
ServerTaskThread task = 
30 new ServerTaskThread( ipAddress , conn, this); 

//process request data 
task . processRequest (); 

35 //start that task. 

task . start ( ) ; 

} 

catch ( InterruptedlOException iie) { 
continue ; 
40 } 
} 

catch (Exception x) { 
x . printStackTrace ( ) ; 

} 



45 } 



synchronized (socket) { 
try{ 

aborted = true; 
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LOCALHOST = false; 
nextID = 1 ; 
socket . close ( ) ; 
socket . notif yAll ( ) ; 

5 } 

catch (IOException ioe){ 
ioe . printStackTrace (); 

} 

} 

10 } 



15 /** reads alternative JAM tags if "jam. tags" 

* property file provided 

* Keys : 

* AppURL - Application URL JAM Tag 

* AppSize - Application Size JAM Tag 

20 * MainClass - Application Main Class JAM Tag 

* AppName - Application Name JAM Tag 

* AppUseOnce - Use -Once JAM Tag 
*/ 

public abstract void loadTagNames ( ) ; 



/** Runtime generation of JAD file, to be sent 

* to the client as result of 

* getNextApp request . 
30 */ 

public abstract ByteArrayOutputStream 
generate JAM (String host, 
int port, 
String next_app, 
35 long length, 

String mainClass, 
String j arLocation , 
String protocolPermissions , 
String agentMoni torlD , 
40 String signature, 

// attaching the client ID to the JAD file. 
ServerTaskThread task) 

throws UnsupportedEncodingException ; 



/** 

* In case that a certain ID is already in use, 

* than the server assign an ID to the client. 
*/ 
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public int getNextID ( ) { 
return nextID++; 

} 

5 /** 

* When an assigned thread was completed its work, 

* we need to remove it from the Isit of threads 

* currently running in the system. 
*/ 

10 public void cleanup ( String signature)! 

synchronized( taskHashtable ) { 

taskHashtable . remove ( signature ) ; 

} 

} 

15 

/** 

* When this class assign new thread for processing 

* the client request, it puts 

* the thread in a hashtable for keeping reference 
20 * to it . If a former thread, 

* that serve a particular client, has not completed 

* yet, the former thread is 

* terminated (generally this case happens 

* when something went wrong) . 
25 */ 

public void putTaskThread (String signature, 
ServerTaskThread serverTaskThread) { 
synchronized( taskHashtable ) { 
ServerTaskThread task = 
30 ( ServerTaskThread) getTaskThread ( signature ) ; 

if (task != null) { 

verboseln ( " task is being stoped" ) ; 
task . stopTask ( ) ; . 
task = null; 

35 } 

taskHashtable . put ( signature , 
serverTaskThread) ; 

} 

} 

40 

/** 

*Get the reference to a client's thread 

* that currently serve the client request. 
*/ 

45 public ServerTaskThread 

getTaskThread ( String signature)! 
synchronized( taskHashtable) { 
return ( ServerTaskThread) 

taskHashtable . get ( signature ) ; 
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Listing 2 

* Communicator is an implementation of client - server 
10 * communication between a test loader 

* and the main JDTS application. The client uses 

* this class in order to make the requests 

* to the server. When the request is ready to be sent, 

* the communicator attaches the client ID 

15 * to the request and than send it to a Sender class 

* that communicates with the server using HTTP. 
*/ 

public class Communicator { 

20 

/** Communicates with the main JDTS application test 
provider. Retrieves current executing test. 

* @return Test object 
25 */ 

public Test getCurrentTest ( ) { 

return getTest ( "/getCurrentTest/ " ) ; 

} 

30 /** Communicates with the main JDTS application test 
provider. Retrieves next test to execute. 

* @return Test object 
*/ 

public Test getNextTest ( ) { 
35 return getTest ( "/getNextTest/ ") ; 

} 



/** Get the test based on the command specified 
40 * @return Test object 

V 

protected Test getTest ( String command) { 
try { 
/** 

45 * client sends get next test command to the server, 

* through the client class, 

* using the getSignature ( ) function, that retrieves the 

* ID from the environment. 
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*/ 

byte[] bytes = client , getNextTest ( command 4- 
getSignature ( ) ) ; 

5 



10 } 

/** Reports results of the test execution 

* @param Test object, which should include test log 

* and execution status (test result) 
15 */ 

public void reportTestResul ts ( Test currentTest) { 

//send test results as byte[] using the client ID. 
client . sendTestResult ( "/sendTestResult/ " + 
getSignature ( ) , encoder . getBytes ( ) ) ; 

20 } 



* Retrieve the the ID from the JAD file. When calling 

25 * getNextApp, the server attached to the JAD file the ID 

* that comes with 

* the request. If there is no ID attached, the ID is 

* the IP address of the agent. 

* This method returns empty String in case that there is 
30 * not ID attached to the JAD file. 

* Any Communicator that extends this class, 

* probably overrides this function to supply 

* its own way for getting the signature from the platform 

* environment. 
35 **/ 

public String getSignature ( ) { 

MIDlet midlet = (MIDlet ) agentManager . getExtender ( ) ; 
String signature = 
40 midlet . getAppProperty ( "Bundle - Signature " ) ; 

if (signature == null){ 
return " " ; 
} 

45 else{ 

return signature; 

} 
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/** Request to perform a communication action in addition 

* to the actions explicitly defined in the interface. 

* @param actionName is the name of the action to be 

5 * performed. The implementation filters actions according 

* to action name . 

* @param actionOb j ects is the array of objects this 

* action might use. The exact type of this objects needs 

* to be known 

10 * to both class who calls the method and to the 

* Communicator implementation 
*/ 



public Object perf ormAction ( String actionName,] 
15 Object[] actionOb j ects ) { 

Object [] obj = new Object[1]; 

if ( actionName . equals ( " ShowTes tDe script ion" ) ) { 
20 return showTestDescription (( String ) 

actionOb j ects [ 0 ] ) ; 

} 



else if ( actionName . equals 
25 ( "ShowTestDescriptionString" ) ) { 

obj[0] = actionObjects [ 0 ] ; 
return ShowTestDescriptionString 
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( obj , (String ) actionOb j ects [ 1 ] ) ; 
} 

else if ( actionName . equals 

( "ShowCombineTestDescription" ) ) { 
obj[0] = actionObjects [ 1 ] ; 
return ShowCombineTestDescription " 
( ( String) actionObjects [ 0 ] , obj ) ; 

} 



else if ( actionName . equals 

( "RecordedShowCombineTestDescription" ) ) { 
obj[0] = actionObjects [ 1 ] ; 

return Re cordedShowCombineTestDe script ion 
15 ( ( String) actionObj ects [ 0 ] , obj ) ; 

} 



else 

return null; //unknown action 



20 



/* * 

* This set of functions create the desired requests 
25 * to the be sent to the JDTS server. 

* The client ID is attached to each request. 
*/ 

private String ShowCombineTestDescription 

(String descFileAndButtons , Object [] outputString ) { 

30 

System . out . println 

( "Communicator . ShowCombineTestDescription : " + 
descFileAndButtons) ; 

35 byte[] bytes = client . sendCommand 

("/ShowCombineTestDescription/" + descFileAndButtons + 
"/" + getSignature ( ) , outputString); 

if (bytes != null) { 
40 String testResult = new String (bytes ) ; 

return testResult ; 

} 

else 

return null; 



45 } 



private String RecordedShowCombineTestDescription 

(String descFileAndButtons, Object[] outputString) { 
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System . out . println 

( "Communicator . RecordedShowCombineTestDescript ion : " 4- 
descFileAndButtons ) ; 

5 byte[] bytes = client , sendCommand 

( "/RecordedShowCombineTestDescription/ " + 
descFileAndButtons + "/" + getSignature ( ) , 
outputString ) ; 

10 if (bytes != null) { 

String testResult = new String ( bytes ) ; 
return testResult; 

} 

else 

15 return null; 

} 

/** Implementation of show test description request 
2 0 */ 

private String showTestDescription ( String description) { 



25 



System . out . println 

( "Communicator . showTestDescription : " + description ) ; 

byte [ ] bytes = client . sendCommand ( "/showTestDescription/ 
+ description + "/" + getSignature () , null); 



if (bytes != null) { 
30 String testResult = new String ( bytes ) ; 

return testResult ; 

} 

else • 

return null; 

35 } 



private String showTestDescriptionString 

(Object[] testlnfo. String buttonsArray) { 
40 byte[] bytes = client . sendCommand 

("/showTestDescriptionString/" + buttonsArray + "/" 4- 
getSignature ( ) , testlnfo) ; 

if (bytes != null) { 
45 String testResult = new String(bytes ) ; 

return testResult ; 

} 

else 

return null; 
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Listing 3 

/ * * 

* Implements the creation of the JAD file. 
*/ 

10 public class HttpServer extends BaseHttpServer { 
/** 

* BaseHttpServer extender applicable for MIDP project 
*/ 

15 

//JAM TAGS (default values set) 

private String profile = "MicroEdition - Prof ile " ; 

private String configuration = "MicroEdition - 
Configuration"; 
20 private String appURL = "MIDlet - Jar -URL" ; 

private String appSize = "MIDlet - Jar - Size " ; 

private String appVersion = "MIDlet -Version" ; 

private String appName = "MIDlet -Name " ; 

private String appVendor = "MIDlet - Vendor " ; 
25 private String midlet = "MIDlet -1"; 

private String useOnce = "Use-Once"; 

private String bundleSignature = "Bundle - Signature" ; 
private String permission = "MIDlet - Permissions " ; 



public HttpServerO { 
super ( ) ; 

ALTERNATIVE_NEXT_APP = "getNextApp . j ad" ; 
35 loadTagNames ( ) ; 

} 



/** Runtime generation of JAM file (applicable for 
DoJa project) 
*/ 

45 public synchronized By teArrayOutputStream 

generateJAM( String host , 
- int port , 
String next__app, 
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long length, 
String mainClass, 
String j arLocation , 
String protocolPermissions , 
5 String agentMonitorlD, 

String signature, 
ServerTaskThread task) throws 
UnsupportedEncodingException { 

10 ByteArrayOutputStream bos = new ByteArrayOutputStream ( ) ; 

PrintWriter pw = new PrintWriter ( new 
Output StreamWr iter (bos , "IS0885 9_1 " ) ) ; 

File jar_path = new File ( j arLocation , next_app); 
15 long jarsize = j ar_jpath . length () ; 

pw. print In (appURL -h ": http://" 
+ host 

+ ":" + port + "/" + next__app); 
20 pw . println ( appSize + " : " + jarsize); 

pw . println ( configuration + ": CLDC-1.0" ); 
pw.println(prof ile + ": MIDP- 1 . 0* ) ; 

pw . println ( appName + ": TestSuite " ) ; // needed by JAM 
pw . println ( appVersion + ": 1.0"); 
25 pw . println ( appVendor + ": Sun Microsystems, Inc."); 

pw . println (midlet + ": TestSuite,, " + mainClass); 
pw . println ( useOnce + ": yes"); 

pw . println (permission + ": " + protocolPermissions); 
//the unique ID is sent to the client. 
30 pw . println (bundleSignature + ": " 4- agentMonitorlD); 

//add meta-info: jad properties specified for the test 
try { 

Hashtable metalnfo = 
35 getTestProvider ( ) . getCurrentAppInf o (signature ) ; 
String[ ] jadprops = (String[]) 
metalnfo . get ( " JadParameters " ) ; 
if (jadprops != null) { 
//write these props to the jad 
40 for ( int i = 0; i < j adprops . length ; i++) 

pw . println ( j adprops [ i ] ) ; 

} 

} catch (Exception e) { 
e . printStackTrace ( ) ; 
45 System . out . println ( "Failed to add jad parameter. 

[IGNORED] " ) ; 
} 

pw . close ( ) ; 
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task . setResponse Property ( "Content - Type" , 
"text/vnd . sun . j 2me . app - descriptor " ) ; 

task . setResponseProperty ( "Content - Length" , " " + 
5 bos . size ( ) ) ; 

return bos; 
} 

10 } 



Listing 4 

/** 

15 * Agent launcher extender compatibile with MIDlet. 

* MIDPRunner is an agent launcher for the MID 

* Profile platform. 

* When the AMS completes the download 

* of the application (JAR file), 

20 * it addresses the JAD file to get the class name 

* (the MIDlet name) to be executed. 
*/ 

public class MIDPRunner extends MIDlet implements Extender 
25 { 

private CLDCRunner runner = null; 
private String bundlelD = null; 

30 public void startAppO { 

/** 

* this is the way get the client ID from the enviroment 

* (from the JAD file) 
*/ 

35 bundlelD = getAppProperty ( "BundlelD" ) ; 



'} 

40 

public void pauseApp(){} 

public void destroyApp ( boolean unconditional) {} 

/** 

45 * Returns MIDPRunner extender object as a MIDlet. 

* In order to get environment settings from other class, 

* you need to get. access to this MIDlet. 
*/ 
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public Object getRunnerExtender ( ) { 
return (MIDlet) this; 

} 

/** Provides MIDP specific way to terminate agent 

V 

public void terminateAgent ( ) { 
notif yDestroyed ( ) ; 

} 



Listing 5 

/** 

15 * This class is the implementation of the 

* thread 44 (Fig. 3). It is used by the server 

* to carry out the client request tasks . 

* According to the client request, this thread 

* communicates with the corresponding 

20 * JDTS component and supplies the client request. 

* Once the thread is started, the main thread of the 

* server returns to listen to new requests from other 

* clients, and the thread handles communication with 

* the current client, until the current request has 
25 * been fulfilled. 

*/ 

public class ServerTaskThread extends Thread { 
/** 

30 * Default get next app . 

* "Thread" is a standard Java class. 
*/ 



protected final String NEXT_APP = "getNextApp" ; 
35 /** Alternative NEXT_APP STRING. Can be adapted per 

* platform 
*/ 

protected String ALTERNATIVE_JSfEXT__APP = "getNextApp"; 
protected final String NEXT_TEST = "getNextTest " ; 
40 protected String NEXT_CMD = " /getNextCommand" ; 

protected String CURRENT_TEST = "getCurrentTest " ; 



/** 

45 * Sets some variable for later execution. 

*/ 

public ServerTaskThread( String ipAddress, Socket conn, 
BaseHttpServer httpServer) { 
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this . ipAddress = ipAddress ; 

jarSourceDir = httpServer . get JarSourceDir ( ) ; 
mainClass = httpServer ; getMainClass ( ) ; 



This function sets the initial variable-, and prepares 
it to serve the client request . 

The thread 44 parses the client request, retrieves the 

client ID, and checks at the main server 

if it is to be serve a client - specif ic request. 

/ 

public void processRequest ( ) { 

String line, method, url , version; 

StringTokenizer cutter ; 

try{ 

in = new 

Dat a Input St ream ( conn . get Input St ream ( ) ) ; 
raw = conn . getOutput Stream () ; 
out = new PrintWriter ( new 

Output StreamWriter (raw, "IS08 8 5 9_1 " ) ) ; 

if ( ! httpServer . getBatchMode ( ) ) { 

Notif ierDialog . disposeNotif ication ( ) ; 

} 

line = in . readLine ( ) ; 

if (line == null) { 
verboseln 

( "Connection failure . Retrying . " ) ; 
return ; 

} 

verboseln ( "got new request: " + line); 
if ( line . indexOf ( "getNextApp" ) != -1){ 
getNextAppReq = true; 

} 

else { 

getNextAppReq = false; 

} 

cutter = new StringTokenizer ( line ) ; 
method = cutter . nextToken () ; 
url = cutter . nextToken () ; 
version = cutter . nextToken () ; 

readHeaders ( in ) ; 
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if (method != null && url != null && version 
!= null) { 
try { 

try { 

request = new URL (url); 
} catch (Ma If ormedURLExcept ion e) { 
request = new URL("http", host, 
port , url ) ; 

} 

//set the client signature. 

signature = setSignature ( ipAddress , 
request . toString( ) ) ; 

if (method, equals (GET) ) { 
taskName = HANDLE_GET; 

httpServer . putTaskThread 
(signature, this) ; 

} else if (method. equals ( POST ) ) { 
taskName = HANDLE_J?OST ; 

httpServer . putTaskThread ( signature , 
this ) ; 
} else- { 

verboseln 

("unknown request method: " + 
method) ; 
sendDiagnostics 

( HTTP_BAD_METHOD , out ) ; 

} 

} catch (Malf ormedURLExcept ion mue ) { 
System . out . println 

("Http server error: " + mue); 
sendDiagnostics 

( HTTP_BAD_REQUEST , out ) ; 

} 

} 

} catch (IOException ioe){ 
ioe . printStackTrace ( ) ; 

} 

} 



The main server class, after assuramce 
that all the parameters for the request 
were set, calls this function 
to start processing the request. 

/ 
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public void run(){ 
try{ 

if ( taskName . equals ( HANDLE_GET ) ) { 

handleGet ( request , out, raw, in); 

} 

else if ( taskName . equals ( HANDLE_POST ) ) { 
handlePost ( request , in, out, raw); 

} 

else{ 

System . out . println ( "Http server error") ; 
sendDiagnostics ( HTTP_BAD_REQUEST , out ) ; 

} 

jcatch (Exception e){ 

e . printStackTrace ( ) ; 

} 

cleanup ( ) ; 

} 



/** 

This function processing HTTP GET requests. 

The request is retrieved from the HTTP request line. 

Then, according to the type of command 

the coresponding functionality is being used. 

/ 

protected void handleGet ( URL request, PrintWriter out, 
OutputStream raw, Datalnput Stream in) throws 
IOException, Exception { 

/* 

*there is no need to retrieve content from the 

* client, because this method handles 

* GET requests . 
*/ 

String ref = ( request . getRef ( ) — null) ? 

: "#" + request .getRef () ; 
String path = request . getFile ( ) + ref; 

if (path. startsWith( testRoot + NEXT_APP) 
I I path. startsWith( testRoot . + 
ALTERNATIVE_NEXT_APP) ) { 

verboseln(path) ; 

String next__app = null; 
try { 

//request for next bundle. 
next_app = 
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testProvider . getNextApp ( signature ) ; 

} 

catch (RuntimeException e) { 
e . printStackTrace ( ) ; 
5 System . out . print In 

("Unable to provide next bundle possibly due to a problem 
on the Client side"); 

System . out . print In 
("Client notified to stop the execution"); 
10 sendDiagnostics ( HTTP_NOT_FOUND , out) ; 

//notification to Client impl that no more bundles 



15 



available . 

} 



return , 



if (next_app == null) { 

sendDiagnostics ( HTTP_NOT_FOUND , out ) 
//notification to Client impl that no more bundles 
//available . 
20 return; 

} 



25 



}• 

30 

//check tags 
httpServer . checkTags ( ) ; 

verboseln ( "next_app : " + next_app) ; 
35 File jar_path = new File ( j arSourceDir , 

next_app) ; 

long length = j ar_path . length () ; 

String agentMonitorlD = 
4 0 get AgentMonitorlD ( request . toString ( ) ) ; 

//call for creating JAD file, and downloaded it 
ByteArrayOutputStream bos = 
httpServer . generate JAM ( host , 
4 5 port, next_app, length, 

mainClass , j arSourceDir , 
protocolPermissions , agentMonitorlD, 
signature, this); 



( next_app . length ( ) == 0) { 
//notification to Client impl that bundles 
// currently unavailable. 
//Client should wait and retry again 
sendDiagnostics ( HTTP_UNAVAILABLE , out) ; 
return ; 
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sendDiagnostics ( HTTP_OK , out ) ; 
raw . write (bos . toByte Array ( ) , 0 , 

bos . size ( ) ) ; 
raw . flush ( ) ; 

} 

// cmd "get next test" 

else if (path. s tartsWith ( testRoot + NEXTJTEST)) { 
verbose In (NEXT_TEST ) ; 
//get the next test from the bundle that belong to 
// this client . 

byte [ ] args = 

testProvider . getNextTest ( signature ) ; 

//save next_test as a currentTest for 

// subsequent calls 

// currentTests . put ( signature , 

if (args == null){ 

httpServer . removeCurrentTest ( signature ) ; 

} 

else { 

httpServer . setCurrentTes t ( signature , 
args ) ; 

} 

setResponseProperty ( "Content - Length" , 
"" + (args == null ? 0 : args . length )) ; 
sendDiagnostics ( HTTP_OK , out ) ; 
if (args != null) { 

raw . write ( args ) ; 

raw . flush ( ) ; 

} 

// cmd "get current test" 
} else if (path . startsWith ( testRoot + 
CURRENT_TEST) ) { 

verboseln ( CURRENT__TEST ) ; 
//get the current test from the bundle that 
//belongs to this client. 
byte[] currentTest = 

httpServer . getCurrentTest ( signature ) ; 

if (currentTest != null) { 

setResponseProperty ( " Content - Length" , 
"" + (currentTest == null ? 0 : 
currentTest . length) ) ; 
sendDiagnostics ( HTTP__OK , out ) ; 



if (currentTest 1= null) { 
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raw . write't currentTest ) ; 
raw . flush ( ) ; 

} 

} 

else { 

throw new 

IllegalStateException 
"getCurrentTest called prior to the getNextTes t " ) ; 
} 

} 

// assume cmd is a request for download of 
//the JAR file to the client, 
else { 

File file = new File ( j arSourceDir , path); 
verboseln ( " f ile download: " + file); 

if ( f ile . isFile ( ) && f ile . canRead ( ) ) { 
try { 

FilelnputStream fis = new 
FileInputStream( f ile) ; 

DatalnputStream fin = new 
DatalnputStream ( f is ) ; 

byte[] buffer = new 

byte [ ( int ) file . length ( ) ] ; 

f in . readFully (buf f er ) ; 

fin . close ( ) ; 

setResponse Property 
( "Content -Type" , 
"application/ j ava - archive" ) ; 

setResponseProperty ( "Content -Length" , 
"" + file. length ( ) ) ; 

sendDiagnostics (HTTP_OK, out) ; 

raw . write (buf fer) ; 

raw . flush ( ) ; 

return ; 

} catch (IOException ioe) { 

System . out . println ( "error : " + 

ioe . getMessage ( ) ) ; 
sendDiagnostics ( HTTP_SERVER__ERROR, 

out) ; 

} 

} 

sendDiagnostics (HTTP_NOT_FOUND, out) ; 

} 

} 
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* This function processes HTTP POST requests. 

* The request is retrieved from the HTTP request line. 

* Then, according to the type of command 

* the corresponding functionality is used. 
5 */ 

protected void handlePost ( URL request, DatalnputStream in, 
PrintWriter out, OutputStream raw) throws IOException { 

String ref = ( request . getRef ( ) == null) ? "" : "#" 
10 4- request . getRef () ; 

String path = request . getFile ( ) 4- ref; 

if ( processCommand( request , post Data , out , raw , path) ) 

{ 

15 verboseln (path + " processed"); 

} 

else 

sendDiagnos tics ( HTTP_NOT_FOUND , out ) ; 

} 

20 

/** 

* These are common actions for POST http methods 
**/ 

25 private boolean proces sCommand ( URL request , byte [ ] 

buf , PrintWriter out , OutputStream raw, String path) 
throws IOException { 

// cmd "send test results" 
30 if ( request . getFile (). startsWith ( testRoot + 

"sendTestResult" ) ) { 

verboseln ( "sendTestResult" ) ; 

//String signature = getSignature (path) ; 
35 test Provider . sendTestResult ( buf ,- signature ) ; 

sendDiagnos tics ( HTTP_OK , out ) ; 
return true; 

} 

//handle storeEventSequence cmd. 
40 else if ( getUIService (" storeEventSequence " , 

path, testRoot, out, raw, buf)){ 
verboseln (path -4- " processed"); 
return true; 

} 



45 



//handle showTestDescriptionString cmd . 

//For TCK tests . 

else if (getUIService 

( "showTestDescriptionString" , path, testRoot, 
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out , raw , buf ) ) { 

verboseln (path + " processed") 
return true ; 



/ /handle ShowCombineTestDescription cmd . 
// For J2SE tests . 

else if ( getUIService ( " ShowCombineTestDescription" , 
path, testRoot, out, raw, buf)){ 
verboseln ( path + " processed"); 
return true; 

} 

//handle compare J2SEOutputString cmd . 
//For J2SE tests . 

else if ( getUIService ( " compare J2SEOutput String" , 
path, testRoot, out, raw, buf)){ 

verboseln (path 4- " processed"); 
return true ; 

} 

else 

return false; 



this method is called when the former task wasn't 
ended normally, like VM_EXIT. When the next 
"getNextApp . j ad" request 

arrives, JDTS checks that the last task had 
finished normally, and. if doesn't then it calls 
stopTask(), to clear the viewer in case of an UI test, 
and calls clean up to close all the streams . 

public void stopTask(){ 
try{ 

if ( automationManager . viewer != null) { 
automationManager . viewer . stop ( ) ; 
automationManager . viewer = null; 

} 

cleanup ( ) ; 
}catch (Exception e){ 

e . printStackTrace ( ) ; 

} 

} 

: This function set to the client its unique ID. In case 
: that the IP is used is a local address (127.0.0.1), 
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* JDTS assigns an ID to the client, Otherwise the IP 

* address IS be used as an ID, to which it is 

* concatenated with another string, which may be an ID 

* attached to the first client request by some outside 

* party . 

*/ 

public String setSignature ( String ipAddress, 
String path) { 

//happens only on the first time that a MIDP client 
//connects to JDTS using the host as a "localhost" 
//string. 

if ( ipAddress . equals (" 1 27 . 0 . 0 . 1 " ) && 
getNextAppReq == true) { 

httpServer . setLocalhostFlag ( ) ; 
String ID = 

String . valueOf ( httpServer , getNextID ( ) ) ; 
verboseln ( " ID = " 4- ID); 
return ID; 

} 

//last request was made using the localhost address and 
//the localHost flag was set, 

//That means that the requests from the client 
//use a signature that was given to the JDTS server 
//and there is no significance to the IP address, 
if ( httpServer . getLocalhostFlag ( ) ) { 
return getAgentMonitorlD ( path ) ; 

} 

//common case. 

String agentMonitorlD = getAgentMonitorlD(path) 
//get an ID that was made by some outside party. 

return ipAddress + "." + agentMonitorlD; 

} 

private String getAgentMonitorlD ( String path) { 
String lastToken = null; 
StringTokenizer st = 

new StringTokenizer (path , "/"); 
int tokensNum = st . countTokens ( ) ; 
while (tokensNum > 0){ 

lastToken = st . nextToken ( ) ; 
tokensNum- - ; 

} 

try{ 

//if next token is a number than the last token 
//is an ID, and an exception is not generated. 
Integer . parselnt ( lastToken ) ; 
return lastToken; 
}catch (NumberFormatException nfe) { 
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} 



//default ID 
return " 1 ' 

} 



* 

A service for UI test 

/ 

private boolean getUIService ( String task, String path, 
String testRoot, PrintWriter out, OutputStream raw, 
byte[] buf) throws IOException { 
" try{ 

synchronized automat ionManager ) { 

verboseln ( "signature = " 4- signature); 
verboseln ( " ipAddress = " + ipAddress); 
//set the client ID before address the UI request. 

automationManager . setSignature ( signature ) ; 
automationManager . setlPAddress ( ipAddress ) ; 

if ( task . equals ( " showTest Description" ) ) { 
return automationManager . 
showTest Description 
(path, testRoot, out, raw); 

} 

else if (task. equals 

( "getRecordedEvent Sequence" ) ) { 
returnautomationManager . 
getRecordedEvent Sequence 
(path, testRoot, out, raw); 

} 

else if (task. equals 

( " storeEventSequence" ) ) { 
return 

automationManager . storeEventSequence 
(path, testRoot, out, raw, buf); 

} 

else if (task. equals 

( "showTestDescriptionString" ) ) { 
return automationManager . 
showTestDescriptionString 
(path, testRoot, out, raw, buf); 

} 

else if (task. equals 

( "ShowCombineTestDescription" ) ) { 
return automationManager . 

ShowCombineTestDescription 
(path, testRoot, out, raw, buf); 

} 

else if (task. equals 
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( "compareJ2SE0utputString" ) ) { 
return automationManager . 

compare J2SE0utput String (path , 
testRoot, out, raw, buf); 

} 

else 

return false; 

} 

}catch (Exception e){ 

e . printStackTrace ( ) ; 
return false; 

} 



private void cleanUp(){ 
try{ 

/* 

*In case that the cleanup call made from a 
*situation of TIMEOUT, meaning that the client 
*has died, there is no need 
*for the following code 

*/ 

if (status == 2){ //Client is ALIVE 
/* 

* Read and block until the end of the input 

* stream, so we know that 

* the client application got the data, not 

* just the low level TCP. 
*/ 

try { 

for ( ; ; ) { 

if ( in . read( ) == - 1 ) { 
break; 

} 

} 

} catch (IOException se) { 
// do nothing 

} 

} 

in . close ( ) ; 
out . close ( ) ; 
raw . close ( ) ; 
conn . close ( ) ; 
} catch ( IOException ioe) { 

ioe . printStackTrace ( ) ; 

} 

//Remove the thread 44 from the active threads list. 
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httpServer . cleanup ( signature ) ; 

> 

} 

5 

Listing 6 

/** 

* Extender is a class that enables an agent to be linked 
10 * with platforms that require their main application 

* class to extend their system class, 

* such as Applet or MIDlet. 

* Extender enables agent to delegate platform specific 

* commands to it . 
15 * 

* @author Victor Rosenman 

* (SUN ISRAEL DEVELOPMENT CENTER) 
* 

*/ 

20 

public interface Extender { 

/** Enables extender to use platform specific way 

* of application termination 
*/ 

25 public void terminateAgent ( ) ; 

/** Retrieves a reference to platform class, which 

* the main application class extends . 

* The agent can provide access to the test program to 
30 * the main application class in the context 

* in which it is running. 

* @return an object, which can be casted to the system 

* class, which extender class extends 
*/ 

35 

public Object getRunnerExtender ( ) ; 

} 

40 
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